Community

In the "good old days" we used to switch to the DR site once a year - practice makes perfect!

The digital banks just "get it" - PSD2 compliabce reqirements saified by a simple API integration.

This is a great article and really sets the scene for the this year.

The main focus at the moment seems to be the drive to for their APIs to comply with the PSD2 mandates:

• March 14th 2019 → FIs must have platforms available for external testing
• Sept 14th 2019 → FIs must go live or face the risk of fines from regulators

1. Make versus Buy - Develop your own API's or simply Buy from a Trusted 3rd Party?
   - How modern/open is your CBS?
   - Do you have the time and energy?
2. Should Bank's also be TPP's?
   - Yes
3. Monetisation
   - The hardest question here - lead or be led?
4. BigTech/FinTech - Competitors or Collaborators?
   - Collaboration is the current favourite.
5. PSD2 and GDPR - dichotomy?
   - Too deep, both are worthy causes mired by poor regulation and implemetion.
6. How do Visa and Mastercard react to PIS?
   - Adapt or die.
7. Different adoption rates for AIS and PIS?
   - They are differnt things, like comaparing newspaper vs letter.
8. Wild West without SCA?
   - A worthy cause mired by poor regulation and implemetion
9. Liability - Banks or TPP's?
   - Follow the money - banks hold the money!
10. PSD3?
    - A second vote on PSD2?

Melvin,

As we all know there is no easy solution for the incmbents with decades of legacy infrastructure to account for.

Building a modern, flexible, service oriented and real time platform accessible through APIs and cable of seamlessly integtrating with the other services required for the end-to-end custoer experience is a good place to start.

Finding the right migration path is much more difficult!

Lu,

Excellent treatment of a simple problem made complex by repeatedly kicking the issues into the long grass.

It is now not just balances, but full access and service that is expected to be 24x7! 

And dont forget the abiltiy to process and respond to all the addional payment payload that ISO20022 will bring!

"Smoke and Mirrors" is living on borrowed time as a viable option.

This should not be rocket science but given the longevity of the current "legacy" systems I can see why there is a desire to get this right at the outset.

Carrying the additional data with the payment make much more sense than trying to route it around the outside with some complex messaging system, but can the legacy endpoints cope and what tolerance should be given for non adoption?

The main lesson to learn from the recent past is that to expect the unexpected and ensure we build in enough flexibility to be future proof. 

Great summary Bob - another smdesign by comitte tgmhat looks to miss the mark.

If there is to be such a "look up" process to confirm recipients, then why not add a little intelligence to flag accounts that have been used for suspected fraudulent purposes in the past and give the customer some actually useful information for their pay/no-pay decision.

This will probably need more than just the recipients bank to be involved in the process!

An excellent case study of legacy platforms constraining business - but in this case the legacy seems to be preventing a while market moving forward, not just a single player.

If there is to be such a "look up" process to confirm recipients, then why not add a little intelligence to flag accounts that have been used for suspected fraudulent purposes in the past and give the customer some actually useful information for their pay/no-pay decision.

This will probably need more than just the recipients bank to be involved in the process!